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Abstract 


This document defines the use of Service Location Protocol version 2 
(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities. 


1. Introduction 
This document describes the use of the Service Location Protocol 
version 2 in performing dynamic discovery of participating Fibre 
Channel over TCP/IP (FCIP) Entities. Implementation guidelines, 
service type templates, and security considerations are specified. 
2. Notation Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
3. Terminology 
Here are some definitions that may aid readers that are unfamiliar 


with either SLP or FCIP. Some of these definitions have been 
reproduced from [RFC2608] and [RFC3105]. 
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User Agent (UA) A process working on the client’s behalf 
to establish contact with some service. 
The UA retrieves service information from 
the Service Agents or Directory Agents. 


Service Agent (SA) A process working on behalf of one or more 
services to advertise the services and 
their capabilities. 


Directory Agent (DA) A process which collects service 
advertisements. There can only be one DA 
present per given host. 


Scope A named set of services, typically making 
up a logical administrative group. 


Service Advertisement A URL, attributes, and a lifetime 
(indicating how long the advertisement is 
valid), providing service access 
information and capabilities description 
for a particular service. 


FCIP Entity The principle FCIP interface point to the 
IP network. 


FCIP Entity Name The world wide name of the switch if the 
FCIP Entity resides in a switch or the 
world wide node name of the associated 
Nx_Port. 


FCIP Discovery Domain The FCIP Discovery Domain specifies which 
FCIP Entities are allowed to discover each 
other within the bounds of the scope. 

4. Using SLPv2 for FCIP Service Discovery 

At least two FCIP Entities must be involved in the entity discovery 

process. The end result is that an FCIP Entity will discover one or 

more peer FCIP Entities. 


4.1. Discovering FCIP Entities using SLPv2 


Figure 1 shows the relationship between FCIP Entities and their 
associated SLPv2 agents. 
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Figure 1: 


As indicated in Figure 1, 


The SA constructs a service advertisement of the type 


"service: 
register. 
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4-------------------------------------- + 

| FCIP Entity | 

4+---------------------------------- + 

| FCIP Control and Services Module | | 

+---------------- + | | 

| SA UA | | | 

+---------------- +----------------- + | 

| TCP/UDP/IP | | 

+---------------- +----------------- + 

| Interface | | 

| 192.0.2.10 | | 

+---------------—- +----------------- +-—-| 
| 

snes ok | 

DA ----+ IP Network 

----+ 

$---------------- +----------------- +--- | 

| Interface | | 

| 192.0.2.20 | | 

+---------------—- +----------------- + | 

| TCP/UDP/IP | 

+---------------- +----------------- + 

| SA UA | | | 

+---------------- + | | 

| FCIP Control and Services Module | | 

4+--------------------------------- + 

| FCIP Entity | 

4+-------------------------------------- + 


FCIP Entity and SLPv2 Agent Relationship. 


July 2004 


each FCIP Entity contains an FCIP Control 
and Services Module that interfaces to an SLPv2 SA and UA. 


fcip:entity" for each of the service URLs it wishes to 


The service advertisement contains a lifetime, 


other attributes defined in the service template. 


along with 


The remainder of the discovery process is identical to that used by 
any client/server pair implementing SLPv2: 


1. If an SLPv2 DA is found [RFC2608], 
registers the service advertisement. 
SLPv2 DAs are discovered, the SA maintains the service 


the SA contacts the DA and 


Whether or not one or more 


advertisement itself and answers multicast UA queries directly. 


Peterson 


Standards Track 


[Page 3] 


RFC 3822 Finding FCIP Entities Using SLPv2 July 2004 


2. When the FCIP Entity requires contact information for a peer FCIP 
Entity, the UA either contacts the DA using unicast or the SA 
using multicast using an SLPv2 service request. The UA service 
request includes a query, based on the attributes, to indicate the 
characteristics of the peer FCIP Entities it requires. 


3. Once the UA has the IP address and port number of a peer FCIP 
Entity, it may begin the normal connection procedure, as described 
in [RFC3821], to a peer FCIP Entity. 


The use of a DA is RECOMMENDED for SLPv2 operations in an FCIP 
environment. 


4.1.1. FCIP Discovery Domains 
The concept of a discovery domain provides further granularity of 
control of allowed discovery between FCIP Entities within a specific 


SLPv2 scope. 


Figure 2 shows an example relationship between FCIP Entities and 
their associated discovery domains within a specified SLPv2 scope. 


fcip 


= BRA EER eB RRA RAMA DS ERIE DLEE AREER DERRER RA KE AEE, AE = 


= * * = 
= * F#FFFOLANGSHHHFET EE HEHEHE EEE EE EE EE kx = 
= * # ------------ I/////eluel//////+// 11/1111 /11/// * = 
= * # | FCIP / + / * = 
= * # | Entitya | / + J * = 
= * # —-——-—-—-—----— / # = ——-——-—-—-—-----— / * = 
= * # / # | FCIP | / * = 
= * # / # | Entity c | / * = 
= * 4# ff oE ee eee / * = 
= * # / | FCIP | # J * = 
= * # / | Entity B | # / * = 
= * 4# Wot wane aaa saa a # / * = 
= x ERTER HE TE RE H E TE HE E TE AE HE TE E HE HEHE E E E E E EE EE E H / * = 
= * ee 
= * * = 
= KEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK = 


Figure 2: FCIP Entity and Discovery Domain Example. 
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Within the specified scope "fcip", the administrator has defined a 
discovery domain "purple", allowing FCIP Entities A, B, and C to 
discover each other. This discovery domain is illustrated using the 
we character . 


Within the specified scope "fcip", the administrator has defined a 
discovery domain "orange", allowing FCIP Entity A to discover FCIP 
Entity B, but not FCIP Entity C. This discovery domain is 
illustrated using the "#" character. 

Within the specified scope "fcip", the administrator has defined a 
discovery domain "blue", allowing FCIP Entity C to discover FCIP 
Entity B, but not FCIP Entity A. This discovery domain is 
illustrated using the "/" character. 


For the example relationship shown in Figure 2, the value of the 
fcip-discovery-—domain attribute for each FCIP Entity is as follows: 


FCIP Entity A = orange, purple 
FCIP Entity B = orange,blue,purple 
FCIP Entity C = blue,purple 
5. FCIP SLPv2 Templates 
Two templates are provided: an FCIP Entity template, and an abstract 
template to provide a means of adding other FCIP related templates in 


the future. 


5.1. The FCIP Abstract Service Type Template 


This template defines the abstract service "Service:fcip". It is 
used as a top-level service to encapsulate all other FCIP related 
services. 


Name of submitter: David Peterson 
Language of service template: en 
Security Considerations: see section 6. 


Template Text: 
template-type=fcip 
template-version=0.1 


template-description= 
This is an abstract service type. The purpose of the fcip service 
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type is to encompass all of the services used to support the FCIP 
protocol. 

template-url-syntax = 


url-path= ; Depends on the concrete service type. 


5.2. The FCIP Entity Concrete Service Type Template 


This template defines the service "Service:fcip:entity". A device 
containing FCIP Entities that wishes to have them discovered via 
SLPv2 would register each of them with each of their addresses, as 
this service type. 


FCIP Entities wishing to discover other FCIP Entities in this manner 
will generally use one of the following example query strings: 


1. Find a specific FCIP Entity, given its FCIP Entity Name: 


Service: service:fcip:entity 
Scope: fcip-entity-scope-list 
Query: (fcip-entity—name=\ff\10\00\00\60\69\20\34\0C) 
2. Find all of the FCIP Entities within a specified FCIP Discovery 
Domain: 
Service: service:fcip:entity 
Scope: fcip-entity-scope-list 
Query: (fcip-discovery-—domain=fcip-—discovery-—domain-name) 


3. In addition, a management application may wish to discover all 
FCIP Entities: 


Service: service:fcip:entity 
Scope: management—service-scope-list 
Query: none 


Name of submitter: David Peterson 
Language of service template: en 
Security Considerations: see section 6. 
Template Text: 
template-type=fcip:entity 


template-version=0.1 
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template-description= 
This is a concrete service type. The fcip:entity service type is 
used to register individual FCIP Entity addresses to be discovered 
by others. UAs will generally search for these by including one of 
the following: 
- the FCIP Entity Name for which an address is needed 
- the FCIP Discovery Domain Name for which addresses are requested 
- the service URL 


template-url-syntax = 
url-path = hostport 


hostport = host [ ":" port ] 

host = hostname / hostnumber 

hostname = *( domainlabel "." ) toplabel 

alphanum = ALPHA / DIGIT 

domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum 
toplabel = ALPHA / ALPHA * [ alphanum / "-" ] alphanum 
hostnumber = ipv4-number 

ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) 


port = 1*DIGIT 


; A DNS host name should be used along with the well-known 
; IANA FCIP port number for operation with NAT/NAPT devices. 


; Examples: 
; service:fcip:entity://host.example.com 
; service:fcip:entity://192.0.2.0:4000 


fcip-entity-name = opaque L 

# If the FCIP Entity is a VE_Port/B_Access implementation [FC-BB-2] 
# residing in a switch, the fcip-entity-name is the Fibre Channel 
# Switch Name [FC-SW-3]. Otherwise, the fcip-entity-name is the 

# Fibre Channel Node Name [FC-FS] of the port (e.g., an Nx_Port) 

# associated with the FCIP Entity. 

# An entity representing multiple endpoints must register each of 
# the endpoints using SLPv2. 

transports = string M L 

tcp 


# This is a list of transport protocols that the registered entity 
# supports. FCIP is currently supported over TCP only. 
tcp 
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mgmt-entity = string MOL 

# The URL’s of the management interface(s) are appropriate for SNMP, 
# web-based, or telnet management of the FCIP Entity. 

# Examples: 

# http://fcipentity.example.com:1080/ 

# telnet://fcipentity.example.com 


fcip-discovery-domain = string M L 

fcip 

# The fcip-discovery-domain string contains the name(s) of the FCIP 
# discovery domain(s) to which this FCIP Entity belongs. 


6. Security Considerations 


The SLPv2 security model as specified in [RFC2608] does not provide 
confidentiality, but does provide an authentication mechanism for UAs 
to assure that service advertisements only come from trusted SAs with 
the exception that it does not provide a mechanism for authenticating 
"zero-result responses". See [RFC3723] for a discussion of the SLPv2 
[RFC2608] security model. 


Once an FCIP Entity is discovered, authentication and authorization 
are handled by the FCIP protocol. It is the responsibility of the 
providers of these services to ensure that an inappropriately 
advertised or discovered service does not compromise their security. 


When no security is used for SLPv2, there is a risk of distribution 
of false discovery information. The primary countermeasure for this 
risk is authentication. When this risk is a significant concern, 
IPsec SAs SHOULD be used for FCIP traffic subject to this risk to 
ensure that FCIP traffic only flows between endpoints that have 
participated in IKE authentication. For example, if an attacker 
distributes discovery information falsely claiming that it is an FCIP 
endpoint, it will lack the secret information necessary to 
successfully complete IKE authentication, and hence will be prevented 
from falsely sending or receiving FCIP traffic. 


There remains a risk of a denial of service attack based on repeated 
use of false discovery information that will cause the initiation of 
IKE negotiation. The countermeasures for this are administrative 
configuration of each FCIP Entity to limit the peers that it is 
willing to communicate with (i.e., by IP address range and/or DNS 
domain), and maintenance of a negative authentication cache to avoid 
repeatedly contacting an FCIP Entity that fails to authenticate. 
These three measures (i.e., IP address range limits, DNS domain 
limits, negative authentication cache) MUST be implemented. 
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6. 


10. 


1. Security Implementation 


Security for SLPv2 in an IP storage environment is specified in 


[RFC3723]. IPsec is mandatory-to-implement for IPS clients and 
servers. Thus, all IP storage clients, including those invoking SLP, 
can be assumed to support IPsec. SLP servers, however, cannot be 


assumed to implement IPsec, since there is no such requirement in 
standard SLP. In particular, SLP Directory Agents (DA) may be 
running on machines other than those running the IPS protocols. 


IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this 
includes ESP with a non-null transform to provide both authentication 
and confidentiality. 


Because the IP storage services have their own authentication 
capabilities when located, SLPv2 authentication is OPTIONAL to 
implement and use (as discussed in more detail in [RFC3723]). 


IANA Considerations 


This document describes two SLP Templates in Section 5. They should 
be registered in the IANA "SVRLOC Templates" registry. This process 
is described in the IANA Considerations section of [RFC2609]. 


Internationalization Considerations 


SLP allows internationalized strings to be registered and retrieved. 
Attributes in the template that are not marked with an ’L’ (literal) 
will be registered in a localized manner. An "en" (English) 
localization MUST be registered, and others MAY be registered. 


Summary 
This document describes how SLPv2 can be used by FCIP Entities to 


find other FCIP Entities. Service type templates for FCIP Entities 
are presented. 
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